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[57] ABSTRACT 
In a distributed computing environment (DCE), a 
scheduler process executes on every DCE processor. 
The schedulers mediate all remote procedure calls 
(RPCs) made by client processes to server processes 
using a scheduler and/or namespace accessible by the 
DCE processor. The scheduler database stores inter- 
faces of single-thread servers, and the liamespace stores 
interfaces of multi-thread servers. The scheduler, in 
response to receiving an identity of an interface from a 
client process searching the scheduler database and 
namespace to locate the interface. Upon locating the 
interface, the interface is provided to the client process 
so that client and server processes can be bound. 
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fact convenient and conventional shorthand references 
METHOD AND APPARATUS FOR ALLOCATING to the operation of one or more processors executing 
SERVER ACCESS IN A DISTRIBUTED instructions comprising the program code.) 

COMPUTING ENVIRONMENT The term "server'* is commonly used to refer to a 

5 computer program, executing on an appropriate proces- 
TABLE OF CONTENTS sor system ("server host"), that carries out service re- 

1 . BACKGROUND OF THE INVENTION quests made by, e.g., other computer programs that may 

1.1 Oients, Servers, and Interfaces, and RPCs in a be executing on the same or other computer systems. In 
DCE Environment most implementations a server executes on a specified 

1 .2 Multi-Threaded Servers computer and receives service requests from other com- 

1.3 Backward Compatibility Problems of Single- puters over a communications network. See generally 
Thread Servers [RKF] at section 1.2. 

1.4 Prior Attfempts to Accommodate Single-Thread More specifically, an RPC "server" is commonly 
Servers in the DCE defined as a "process" that "exports" one or more "in- 

2. SUMMARY OF THE INVENTION tgrf^ces" capable of being invoked by remote clients. A 

2.1 Basic Operation "process" refers generaUy to the execution by a physi- 

2.2 Transactional Context cal processor (or processor system) of one or more 

2.3 Cache of Known Servers series of instructions in a specified "address space,", i.e., 

3. BRIEF DESCRIPTION OF THE DRAWINGS ^ g stem environment that includes particular physical 

4. DETAILED DESCRIPTION OF SPECIFIC EM- ^0 ^^^^^^ allocations, open files, static data, etc. 
BODIMENTS Xhe tenn "interface" in the DCE environment refers 
4.1 Primary Elements and Associated Procedures generally to a formal specification of inputs and outputs 

4.1 (a) Scheduler Location of an Interface ^ specified service, wherein a service request that 

4.1 (b) Client Queuing complies with the input specification results in a server 

4.1 (c) Releasmg the Process generate output that complies with the 

4.1 Transaction^Cc^^^ specification. The term "export an interface" 

t-l ti"^^^ ^^hI^ generally refers to the transmittal by a server process of 

linf Trf.f^'^^^^ ?re-fonnatted information containing interface and 

ri A TMS ^^^^ 30 bindmg specifications to a namespace server for recor- 

AR^T^A<-r <iation in a "namespace" server data structure." See 

AtJJ* i KA^ 1 generally [RKF] section 9.3. 

BACKGROUND OF THE INVENTION Generally speaking, a client process that desires to 

The invention relates to a method for locating and invoke a server interface sends a request (e.g., an RPC) 
scheduling access to "servers" in a distributed comput- 35 to the namespace server requesting a "bmding handle 
ing environment More specifically, the invention re- for the server in question that impUcitiy encodes the 
lates to a metiiod for locating and scheduling access to network address of the server, the client may subse- 
servers that operate in the OSF distributed computing quently use the bindmg handle in a single RPC to re- 
environment commonly referred to as *T)CE." The quest that services be performed by the server. The 
invention is particularly useful with respect to access to 40 client may indicate via an RPC argument that the serv- 
a single-thread DCE server process by a context-sensi- er*s services are desired over a series of RPCs in con- 
tive client process. nection with a •'transaction," Le., a series of related 

The discussion below refers at several points to a service requests. In such a situation the server m Ri n t ain s 
useful reference work by three employees of the as- "context," the system state, and the binding handle 

signee of this application, "Understanding DCE," by 45 remains valid, until the client indicates (again via an 
Ward Rosenberry, David Kenney, and Gerry Fisher argimient) that the transaction is complete. 

(Sebastopol, Calif.: O'Reilly & Associates, Inc., 1992), jj^yg^ ^ server that exports an interface in effect is 
hereinafter referred to as [RKF], which is incorporated announcing (to "client" processes that are designed 
by reference as background information well-known to ^^^^ ^ ^^^^ knowledge of the interface) that the speci- 
those of ordinary skill. 30 outputs can be obtained from the server 

1.1 CUents, Servers, and Interfaces, and RPCs m a DCE process. See generally [RKF] section 3.3. 
Environment ^^^^ implementations a smgle copy of the names- 

In the OSF DCE enviromnent, servic^ requ^ts may ^^^^^ maintained, with all server access 

be transmitted as "remote procedure (RPCs) tiiat ^ processed at that copy. In larger imple- 

conform to a standard specificauon. RPC^ permit stan- 55 ^^^^^ ^ P ^ ^^^^ of network nodes, it 
dardized commumcauon ^o^S ^^^^enu^^ and even ^ j^^^e more efficient to maintain a copy of the names- 
nonstandard components m a DCE network. 8 ^ 

A special category of program mstrucuons m the f*^»?ivci avo^ ^^toi , ^. 

DCE^^omnen^is^referre^ P«^<'%^ "^"^^ 7^TJZ 

aUy speaking, stub code comprises standard program 60 POses. In either case, a node on which a copy of the 
instructions tiiat act as a communications interface be- namespace server is mamtamed is referred to herem as a 
tween a main program (either a client program or a namespaceserver. 
server program) and one or more remote processes. See 1.2 Multi-Threaded Servers 

generaUy plKF] sections 3.1,2 and 3.5. The DCE environment permits a wide variety of 

(Those of ordinary skill having the benefit of this 65 computer systems and subsystems to be connected 
disclosure will of course recognize that descriptions of together for mutual sharing of resources. Some systems 
program code performing a particular function, e.g., may be capable of multi-thread operation, while others 
stub code "acting" as a communications interface, are in may be capable only of single-thread operation. 
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(As is well-known to those of ordinary skill, generally a global lock it can execute to completion, secure in the 

speaking a "thread" is a sequence of computer instruc- knowledge that no other thread will execute simulta- 

tions. A given process may have multi-thread capabil- neously utilizing the resources controlled by the global 

ity. That is, the operating system supporting the process lock. Because client processes can rarely be certain that 

may be designed so that the physical processor system 5 service requests will not involve non-reentrant code, 

rotates its actual processing activity among several nearly all requests will indeed involve obtaining the 

different series of program instructions, or "threads," in global lock. Operation in such a mode can essentially 

a specified sequence, or possibly in accordance with a paralyze the client processor system (especially in the 

priority scheme, with all threads using the same address event of a "hangup" in a thread that has the global lock) 

space.) 10 eliminate the benefits of multi-thread computing. 

The OSF DCE specification assumes all servers to be A variation on the global lock solution is the "jacket 
multi-thread in nature and thus able to handle multiple routine," which represents a refinement of the basic 
concurrent calls. A multi-thread DCE server comprises global lock concept with respect to certain commonly 
a single process capable of executing multiple threads used, non-reentrant, UNIX system calls. In order to 
by sharing the process's address space among its threads 15 enable the use of these system calls, DCE Threads (an 
using mutexes (mutxial exclusion locks) or global locks. implementation of threads standard in the DCE), pro- 
Such m^hanisms are used to protect portions of mem- vides a jacket routine. Instead of making a UNIX sys- 
ory that must remam constant while a particular thread tern call, threads call the corresponding jacket routine, 
"waits" for the processor's attention (i.e. while the pro- The jacket routine acquires the global lock, runs, then 
cessor is executing instructions from another thread). 20 releases the global lock. See generally [RKF] section 
When a service request or "call" is received by a multi- 4.2. The use of jacket routines can cause the same prpb- 
thread server, a specific thread (referred to as a "call lem as the use of global locks. 

executor" thread) is allocated to handle the call. As Two other potential solutions are proposed in a mem- 
each thread completes its processing of a call, it be- orandum dated Sep. 4, 1992, privately distributed by 
comes available for assignment to another call. See 25 Tandem Computer Corporation, a copy of which is 
generally [RKF] chapter 4. being filed with an information disclosure statement in 
A single-thread process intended as a would-be conjunction with this application. The first proposed 
server, on the other hand, would be able to handle only approach assumes the use of single-thread DCE servers 
one request for service at a time. Service requests would in conjunction with a "monitor process" that directs the 
necessarily be executed serially instead of concurrentiy. 30 clients to bind and rebind witii the appropriate server. 
(Single-thread processes are sometimes referred to as Specifically, the client: 1) issues an RFC to the monitor 
"non-reentrant" because they cannot share an address asking for a binding for an idle server; 2) uses the bind- 
space among independent service requests.) ing to issue at least one RFC to the server; and 3) issues 

1.3 Backward Compatibility Problems of Single-Thread an RFC call to the monitor to release the server. The 
Servers 35 advantage of this approach is that the server can only be 

Single-thread servers present a fundamental problem accessed by one client at a time and that the client can 
in the DCE environment because the design of the access servers on more than one host. A disadvantage to 
DCE assumes that any necessary scheduling of server this approach is performance, because it requires RFC 
resources for handlmg service requests is handled lo- calls every time a server is selected, 
cally at each server. As noted above, the DCE protocol 40 The Tandem memorandum recognizes that some 
is designed to permit the sending of multiple concurrent problems would exist with this approach. First, once a 
requests to a single server. See generally [RKF] section server is allocated to a particular cHent process, it is 
4.2. The lack of backward compatibility with existing unavailable to other clients until the particular client 
single-thread application programs that cannot be used issues a release RFC to the monitor. That allows the 
as DC^ servers thus presents a significant "chicken and 45 client to make several RFC calls while in possession of 
egg" barrier to the growth of DCE computing. Specifi- the server. Because the client may wait an arbitrary 
cally, the present size of the DCE installed base might length of time between calls (subject to any system 
not justify the cost and difficulty of creating thread- timeout constraints), the server may sit idle for signifi- 
compUant implementations from non-reentrant soft- cant periods of time. Furthermore, runtime threads may 
ware- Many existing computer systems operate environ- 50 be blocked resxUting in network problems. Second, the 
raents where single-threaded (and therefore non-reen- allocate and release calls increase network traffic. Third 
trant) server-type software is assumed. Vendors of such and perhaps most significantly, the setup overhead (for 
"legacy" software often are economdcally forced to establishing a connection) is repeated every time a client 
allocate resources to servicing their own installed base switches from one server to another, 
of non-reentrant products. It follows that for such ven- 55 The second approach proposed in the Tandem mem- 
dors, conversion to thread compliance might not be a orandum seeks to solve the problem by enhancing the 
priority until the DCE installed base expands. Such server's duties and- subdividing it into two process 
expansion might not occur, however, until the availabil- types: I) a "server master process" that would act as the 
ity of software expands. communication endpoint and the place where RPC 

1.4 Frior Attempts to Accommodate Single-Thread 60 runtime state is maintained; and 2) an "agent process" 
Servers in the DCE that would run the application manager code. The 

To some extent, the creators of the DCE environ- agent process thus would serve as an extension of a call 

ment anticipated backward compatibility problems. As executer thread of the server master process, with one 

a result, a limited workaround was designed into the agent process assigned to each client request. This divi- 

standard DCE software. The basis of the solution is the 65 sion of function would allow the server's stub code and 

availability of a "global lock." Under this scheme, if a its manager function to run in separate processes 

thread must execute non-reentrant code then it must thereby eliminating scheduling and protection prob- 

first acquire the global lock. Once a thread has acquired lems. 
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A posfflble disadvantage of the agent-process ap- Therefore, after using the server, the client must invoke 
proach would be the overhead associated with two a 'binding release service" to notify the scheduler that 
context switches per RPC. Moreover, it might be neces- the chent has released the server. This allows the sched- 
sary for the server master-process program to be de- uler to re-allocate the server to another client, 
signed with knowledge of every agent-process pro- 5 2 2 Transactional Context 
gram, which could be an administrative burden espe- 
cially in terms of keeping the server master-process One embodiment of the invention is concerned with 
program up to date. "transactional context." Transactional context refers to 

,^„r^^T-r.V^vT the situation where a client, while acquiring a binding 

2. SUMMARY OF THE INVENTION of the binding is to be 

In a system in accordance with the invention, a coordinated with the currently executing transaction, 
"scheduler" program executes on every DCE supervi- When the client initiates a transactional contest the 
sor host Each scheduler transparently mediates all scheduler proceeds as follows: 1) if the same client 
RPCs directed to the copy of the DCE interface data- invokes the binding resolution service for the same 
base and/or namespace residing on that DCE supervi- IS interface, during the same transaction, then the sched- 
sor host The scheduler maintains and utilizes a "sched- provides the same binding handle; 2) the scheduler 

uler database" (Schd-DB) of single-thread servers that coordinates with the "transaction manager" to other- 
is functionally analogous to, but separate from, the prevent the reallocation of the same binding ban- 
DCE namespace. die until the executing transaction is completed. 

A server exports an interface by calling the standard 20 |^ transactional context, once the client establishes 
DCE RPC export services or by calling the scheduler context with a server process, the context persists 
program. If the server exporting the interface is multi- throughout the transaction without further burdening 
threaded, it calls the standard export services to pass the ^jj^j^ Furthermore, the client need not invoke a 

information to the namespace server and/or endpoint binding release service because the scheduler has coor- 
mapper. On the other hand, if the server e:q)orting the 25 ^^^^^ the transaction manager. Via their pre- 
interfece is single-threaded, then it exports its interface established agreement the transaction manager notifies 
by calling the scheduler that in turn installs binding ^j^^ scheduler that the transaction is over so the server 
information for the exporting single-threaded server in released. 

the scheduler database. I„ addition to multi-process servers, transactional 

When the scheduler receives a request for a bindmg 30 ^ ^ny server located via the scheduler 

to a particular server, it attempts to fill the request fron^ ^ namespace. This is because the "binding 

in orden 1) a cache of recait binding request, then 2) ^^^^ service" may be invoked to obtain the bind- 
from the Scheduler DB, and finally 3) from the names- ^.^^ ^ multi-piocess server or for any server 

pace server. , . . - . , , „ registered in the namespace. Specifically, when the 

Thus, broadly speakmg the mvention is roughly and- 35 ^^^^ ^ bindinfresolution service, the client 
ogous to an adapter that permite an American « Hz ^ interface. The scheduler searches for 

electncal appb^ce (a «?^«-*^'[jf^«> the interface, first in the scheduler database then in the 

plugged mto a European 50 Hz waL sockrt (^e D^ ^ .\j,^efore, the client can access either a 
env^omnent) by allowmg the use of non-reentran rou- ^ J or an RPC server registered in the 

taesm theDCEenvimnm^mt Itacwm^^ 40 P ^^^^ ^^pj^. 

by mamtammg "context" between se.v« and chart. P « ^j,^ 

Thjs "adapter" faaUtetes expansion of the DCE m- implementation allows 

staDed ba« thereby hdpmg rtsolvc the chicken and egg J^°^ ^ multi-threaded serv- 

problem descnbed above. ^^^^ affecting the client programs because the 

2.1 Basic Operation client does not know what kind of server it is calling. 

In accordance with the invention, upon RPC initial- Therefore, the cUent can remain w.disturb«l ^ 
izatioreach process of each multi-pr<S:ess server exe- ate'Wessasusvml 'eventfasmJe^^ 
cutes tiie nomally required RPC initialization opera- upg«ded to a multi-threaded server, 
tions and rpc_ listcn( ) in order to receive requests. As 50 2.3 Cache of Known Servers 

part of initialization, each process registers its existence . .t... o„t.^„w :„ o«nfi»,.r.,4 tn 

With the Schd-DB by providing the same data as re- ^ another embodiment the scheduler is configured to 
jTed for standard RFC server registration. P".^"** T h 

CUents of multi-process servers obtain services by an mternal cache of known servers ^d corresponding 
inwldng a "binding resolution service" of the scheduler 55 addresring mformaUon. If the scheduler finds an appro- 
to 6b Jn a bindiig handle to an appropriate RPC priate bindmg m the cache then a database call is 
server. More specifically, a client invokes a binding avoided thereby conserving tmie and network re- 
rS^lution servi^ by providing the scheduler with the sources. This cachmg mechamsm is particuterly smt^ 
same set of data as required by a standard RPC interface to environments hke that of commercial systems where 
when obtaining a server binding handle. The scheduler 60 the same set of services are mvoked repetitively, 
then consults the Schd-DB which maintains a database ^ BRIEF DESCRIPTION OF THE DRAWINGS 
of processes and the availability status of each. If an " - u • t^j- 

appropriate process is available, the scheduler provides HG. 1 shows the pnrnary element of a basic embodi- 
the corresponding binding handle to the client If all ment of the invention. The muln-threaded server 113 
appropriate processes are being used then the client is 65 provides information to the namespace 107. -Hie mulo- 
put in queue by the scheduler. process server 111 provides mfonnation to the sched- 

Because a multi-process server has only one thread, uler DB 105. The client process 101 makes requesB tiiat 
the requesting client obtains control over the server. are handled by the scheduler 103. The scheduler 103 
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uses scheduler DB 105 and namespace 107 to help han- ^ . . ^^.^^ Oueuine 

die the client's 101 request. ' ^ ^ ^ 

FIG. 2 shows the elements involved in the implemen- When an appropriate interface is found m the sched- 

tation of transactional context. The transaction manager uler DB 105, the scheduler 103 transfers to the client 

201 mediates between the servers 113, 114 and the cli- 5 101 a binding for a multi-process server 114. The bind- 

ents 101.203. As shown, client 101 has already received ing enables the client 101 to locate and access the de- 

a binding handle 202 from scheduler 103. sired server 114. 

FIG 3 shows the elements directly affected by the Sometimes, the scheduler 103 finds an appropriate yet 

use of an enhanced scheduler 301. Enhanced scheduler unavaUable interface in the scheduler DB 105. Smce 

301 comprises storage unit 302. 10 multi-process servers 114 are single threaded, the sched- 

FIG. 4 is a flow diagram for a method of the inven- uler cannot assign multiple chents to a smgle server. 

Therefore, if no appropriate mterfaces are available, the 

FIG. 5 is a data flow diagram for one embodiment of scheduler 103 places the client 101 in its queue. 

... When an appropriate mterface is found m the names- 

tne invention. scheduler 103 transfers to the client 101, a 

4. DETAILED DESCRIPTION OF SPECIFIC binding to a multi-threaded server 113. If no threads are 

EMBODIMENTS available, the standard RPC queuing mechanism acti- 

A detailed description of the architecture of a method vates. 

in accordance with the invention is set out below. In the 4. 1(c) Releasing the Process 

interest of clarity, not all features of an actual imple- definition, a client 101 only accesses a 

mentation are descnbed m this specification. I wdl of ^^^^^^ J^^ ^^^^^ p^^^^ 

course be appreciated that m the development of any ^^^^ ^^^^ ^^.^^^ ^^^^ resources to accom- 

such actual unplementation (as m any software develop- ^ ^^^^^ ^ ^^^^^ completes its task 

ment project), numerous programmmg decisions must multi-process server 114, then cUent 101 must relin- 

be made to achieve the developers' particular goals and ^ binding handle 202. When releasing binding han- 

sub-goals (eg., compliance with system- and busmess- 202, client 101 mvokes a "binduig release service." 

related constraints), which wUl vary from one imple- ^ binding release service notifies the scheduler 103 that 

mentation to another. Moreover, attention will ncces- server 114 is released thereby allowing reallocation 

sarily be paid to, e.g., proper serialization to handle resource, 
concurrent events. It will be appreciated that such a 

development effort might be complex and time-consum- 4. 1(d) Transactional Context 

ing, but would nevertheless be a routine undertaking of -j^^ elements of FIG. 1 can operate in an alternate 

program development for those of ordinary skill having embodiment called the transactional context. In the 

the benefit of this disclosure. 35 transactional context, the scheduler 103 slightly 

4.1 Primary Elements and Associated Procedures changes its procedure in order to accommodate a 

4.1 (a) Scheduler Location of an Interface ^^^^^^V different request from the cUent 101. FIG. 2 

twuit^ shows the pnmary elements mvolved m transacUonal 

FIG. 1 shows the conceptual elements of one embodi- context operation. Transaction manager 201 is ex- 

ment of the current invention. Upon RPC mitialization, ^ plained in X/Open documentation, specifically the 

a single-thread, multi-process server 114 registers itself "X/Open Guide, Distributed Transaction Processing 

in a scheduler database 105. Also upon initialization, a Model" distributed by X/Open Co., Ltd., ISBN 1 

multi-thread, single-process server 113 registers itself in 872630 16 2. Briefly, the fimction of the transaction 

namespace 107 by providing an interface identifier and manager 201 is to monitor transactions to assure that 

binding information. If there were other servers pres- 45 they are atomic. As a result, transaction manager 201 

ent, all multi-process types would register in the sched- knows when client 101 begins and ends a transaction 

uler database 105 and all multi-thread types would reg- ^th any server. FIG. 2 illustrates the discrete point in 

ister in the namespace. time occurring just after the client 101 has acquired a 

At some future point, client 101 decides to access a binding handle 202 from the scheduler 103. 

server. Toward that end, client 101 requests a binding 50 When acquiring a binding, the client 101 may notify 

for a specific server interface by providing an interface the scheduler 103 and activate transactional context As 

ID. The request is received by the scheduler 103 which a result, the scheduler 103 alters its behavior. The 

in turn initiates a search for an appropriate interface. scheduler 103 coordinates with the local transaction 

The scheduler 103 searches two data structures, one manager 201 such that the transaction manager 201 

after the other: 1) The scheduler database 105; and 2) 55 notifies the scheduler 103 when the transaction is termi- 

the namespace 107. First, the scheduler 103 calls the nated. Scheduler 103 does not reallocate the same bind- 

scheduler database 105 to check if any multi-process ing handle until the transaction is terminated, other than 

server 114 offers an appropriate interface. If an appro- to the same client seeking the same interface. For exam- 

priate interface is found in the scheduler DB 105 then pie, suppose client 101 makes a subsequent request for 

the search is terminated and the binding of the found 60 the same interface, before the transaction is terminated, 

interface is transferred to the requesting client 101. If an Scheduler 103 assigns the same binding handle 202. 

appropriate interface is not found in scheduler DB 105, However, if during the transaction, other client 203 

then the scheduler 103 continues its search calling the requests the same interface from the scheduler, then 

namespace 107. If an appropriate interface is found in scheduler 103 does not assign binding handle 202 even if 

namespace 107, then the corresponding binding is trans- 65 client 101 is not accessing its assigned interface (server 

ferred to the requesting client 101. If an appropriate 113 or 114) at the time. 

interface is not found m the namespace 107, then the Transactional context allows a client to establish and 

scheduler 103 generates an error message. maintain context with a server throughout a whole 
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transaction. When the currently executing transaction is block 406, if no appropriate binding was found control 
over the transaction manager 201 notifies scheduler 103 passes to block 407 and the namespace is searched for an 
and then scheduler 103 makes binding handle 202 avail- appropriate binding. Control automatically pa^ to 
able for allocation. Since the scheduler 103 is notified by decision block 408. If no binding was found m the 
the transaction manager 201, it is unnecessary for the 5 namespace then control passes to block 409 and an error 
cUent to invoke the binding release service. message is generated. If a binding was found m the 

namespace then control passes to block 410 and pro- 
4.2 An Enhanced Scheduler Embodunent through to 412 as outiined above. 

The embodiment of FIG. 1 may also be implemented This method can drastically increase the efficiency of 
with an enhanced scheduler 301. The enhanced sched- 10 locating a binding. Efficiency gains are realized if the 
uler 301 operates essentially identically to the scheduler scheduler can search storage unit 302 relatively fast as 
103 except the enhanced scheduler 301 incorporates a compared to searching tiie scheduler database 105 or 
storage unit 302 and uses a more complex method to the namespace 107. A search of the storage umt 302 is 
locate an appropriate binding. FIG. 3 shows the ele- inherentiy fast relative to the other searches because the 
mentsdirectiy affected by the use of an enhanced sched- 15 storage unit 302 typk:ally contains fewer entries tiian 
uler 301. *® namespace 107 or scheduler database 105. The stor- 

Storage unit 302 can be any medium for data storage. age unit 302 can achieve an additional and non-inherent 
It can be physically located in any memory accessible to speed advantage tiurough its location. ConceptuaUy, tiie 
tiie scheduler 301. In one embodiment, storage unit 302 storage unit 302 is fastest to search if it is located within 
holds a record of "contexts" that were created by previ- 20 the scheduler 301. Physically, such memory is bkely to 
ous binding assignments. For example, after RFC ini- be located in dedicated cache or in memory space allo- 
tialization, client 101 may invoke a bmdmg resolution cated solely to the scheduler, 
service from enhanced scheduler 301. In response, en- Transform Model 

hanced scheduler 301 may locate binding 202 and assign 

it to dient 101 Enhanced scheduler 301 would then 25 The invention can be descnbed as a collection of data 
store the connection context in storage unit 302. More transforms and data structures. FIG. 5 is a data flow 
specifically, the scheduler 301 stores bmding 202 along diagram for an hnplementation of the mvention de- 
w^th information that keys binding 202 to a specific scribed in data-transfonn terms. The data flow caB be 
^^gj^^g conceptually divided mto two sections: 1) Establish 

The storage unit 302 holds data for any convenient 30 Connection data transform 527 which is implemented 
length of time. In tiie transactional context, a very effi- by tiie Connection Mapper component tiiat resides m 
ci^t form of binding resolution is achieved by using tiie client address space; 2) Schedule Servers date trans- 
storage unit 302 as a cache type memory storing cUent- form 526 which operates in tiie targeted operatog sys- 
/server relationship data. In tiiis configuration, tiie re- tem environment and physical environment. The Re- 
questing cHent makes a binding request and indicates a 35 ments of FIG. 5 are definedas follows: 
ttansactional context Thestorageumt302maytiien be Service Requestor 510: This is tiie user of system 
required to hold tiie context data for a lengtii of time services (e.g., a client process). ^. ^. . , . 
ST to tiie transaction lengtii. The schedulers easy Binding 508: This mdicates tiiat a bmdmg is bemg 
Scess to tiie storage unit results in greater efficiency transferred from one node to an^er. ^^l^'^ 
when tiie same client requests a binding for tiie same 40 binding is address information sufficient for an RFC 

interface ^ "^^^^^ ^ 

Get Bindmg From Context 501: This is a data trans- 

4.3 Method of Searching for Bindings f^j^ th^^ retrieves the bindings from connection con- 
In one embodiment, tiie invention uses the metiiod text 502 (connection context 502 is analogous to storage 
outiined in FIG. 4 to retrieve and assign bindings. Re- 45 unit 302). . . * * 
ferring to FIG. 3, storage unit 302 is used to preserve Access Namespace 511: Tlus mdi^te that the stan- 
context files contaming data which describes tiie rela- dard DCE RFC namespace is mvoked to obtem a bind- 
tionship between bindings and interfaces. ing. This is used to obtam bindings for standard multi- 
Referring to FIG. 4, block 401 shows that tiie method tiiread servers. ^ u o * u 
begins when a chent requests an interface. Control 50 Connection Context 502: A data store used by Estab- 
moves to block 402 where tiie first task of the metiiod is lish Connection 527 which contains zero or more con- 
to check in tiie context files for an appropriate interface. nection context elements, as well as a transaction hash 
Control automatically passes to decision block 403. If an table of pointers used to qmckly locate connection con- 
appropriate interface was found tiien decision block 403 text elements associated witii a particular transaction, 
passes control to block 404 and a bmding is assigned to 55 This is analogous to storage umt 302. 
tiie client From block 404 control passes to block 413 Connection Registration 506: An aggregate data ele- 
which directs control to go to tiie next cUent request. ment containing information used by Establish Connec- 
Moving back to dedsion block 403, if no appropriate tion 527 to maintam the state of tiie chent-to-bmdmg 
record was found in tiie context files, control is passed relationship. This information comprises tiie cbent for 
to block 405 and the scheduler database is searched. 60 which this information is being mamtamed, the transac- 
Control then automaticaUy passes to decision block 406. tion identification, tiie namespace— entryname the 
If an appropriate interface was located in tiie scheduler server interface specification, tiie source of tiie bmdmg 
database tiien control passes to block 410 and tiie bind- information (eitiier Schedule Servers 526 or Accks 
ing is assigned to tiie requesting cUent. Control tiien Namespace 511), the context semantics specified by the 
to block 411 and tiie context fdes are updated. 65 client, and the binding. Update CX State 505: This man- 
Specifically, the server/cUent relationship is stored as a ages information in Connection Context 502. Manage- 
context Control tiien passes to block 410 and is directed ment tasks comprise: 1) addmg entnes that are success- 
to tiie next client request. Referring back to decision fully obtained from tiie namespace or tiie scheduler 
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database; 2) removing entries when transactions are 
completed. 

Txn End 504: The Demarcate Transaction data trans- 
form calls this routine to indicate the specified transac- 
tion has completed. The Establish Connection data 5 
transform uses this indication to terminate the transac- 
tion's client-server relationship(s) and release any bind- 
ing information maintained for this transaction. This 
routine accepts one argument, namely the transaction 
identifier (TID). 10 

Demarcate Transaction 503: Provides services to 
begin, end, and signal completion of a transaction. For 
example Txn End 504 signals a the end of a transaction. 

Get Binding From Namespace 507: Calls Access 
Namespace 511 to retrieve a binding. If a binding is IS 
successfully retrieved, it is sent to Service Requestor 
510 and information is passed to Update CX State 505 so 
that Connection Context 502 may be updated. 

Get Binding From Scheduler 525: Calls Schedule 
Servers 526 to retrieve a binding. If a binding is success- 20 
fully retrieved, it is sent to Service Requestor 510 and 
information is passed to Update CX State 505 so that 
Connection Context 502 may be updated. 

Request Context 513: This represents a data store that 
contains the transaction identification for the current 25 
transaction. 

Server Release 528: Information used by Schedule 
Servers 526 to de-allocate a server process previously 
allocated by Establish Connection, 

Register Interface 523: This routine calls the DCE 30 
RFC runtime to register the server's interface(s) and 
obtain a vector of bindings. The bindings for single 
threaded servers are exported to the scheduler database 
517. The bindings for multi-threaded servers are ex- 
ported to the namespace using the standard DCE RFC 35 
naming export services. 

Unregister Interface 519: This routine is provided to 
unregister a server interface from the scheduler data- 
base 517. 

Allocate Server 514: This routine accesses the sched- 40 
ulmg database to allocate an available server process of 
a MPST (multi-process, single threaded) server identi- 
fied by the interface ID. 

Deallocate Server 524: This routme changes the sta- 
tus of a previously allocated server process to be avail- 45 
able and checks if there is any waiting client on the 
waiting list for the particular MPST server. If so, it 
writes to the client process* FIFO to notify the avail- 
ability of such server process. 

Scheduling DB 517: Scheduling DB is the repository 50 
for server scheduling data. 

Service Entry 518: Service Entries are entries in the 
Scheduling Database representing a MPST server. 

Server State 516: "Server State" represents the state 
of the specified server process within a MPST server 55 
(or what the state should be). 

String Binding 515; String Binding contains the char- 
acter representation of a binding handle. 

Process Context data 520: This represents the data 
that is required for a server to register or unregister it 60 
interfaces. Specifically, it is the identification of the 
server's interfaces. 

It will be appreciated by those of ordinary skill hav- 
ing the benefit of this disclosure that numerous varia- 
tions from the foregoing illustration will be possible 65 
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without departing fi^om the inventive concept described 
herein. For example, those of ordinary skill having the 
benefit of this disclosure will recognize that logical 
functions described above as being implemented in soft- 
ware can equivalently be implemented in hardware, 
e.g., through the use of discrete logic circuitry, and vice 
versa; likewise, a general-purpose processor operating 
imder program control could equivalently be replaced 
by one or more special-purpose chips designed to per- 
form the programmed functions; and so forth. 

Accordingly, it is the claims set forth below, and not 
merely the foregoing illustration, which are intended to 
define the exclusive rights claimed in this application. 

What is claimed is: 

1. In a network of processors and a memory con- 
nected to each other by a communications bus, the 
processors to execute processes and each processor 
executing a scheduler, the processes including clients 
and servers, each server including an interface having 
an identity, the servers including single-thread servers 
and multi-thread servers, a method for binding a client 
to a server comprising: 

registering the interfaces of the single-thread servers 
in a scheduler database of the memory; 

registering the interfaces of the multi-thread servers 
in a namespace of the memory; 

providing, by a client executing on a client processor, 
an identity of an interface to a scheduler, the sched- 
uler executing on the client processor; 

searching, by the scheduler, the scheduler database 
using the identity to locate the interface of a single- 
thread server, and if the interface is not located in 
the scheduler database, then searching the names- 
pace to locate the interface of a multi-thread 
server; and 

providing, if the interface was located in the schedu- 
lar database and if the single-thread server is avail- 
able and otherwise if the interface was located in 
the namespace, the interface to the client to bind 
the client to the server. 

2. The method of claim 1 wherein the memory in- 
cludes a context database, and further comprising: 

in response to providing the interface to the client, 
storing information related to the client, the server, 
and the interface in a context database of the mem- 
ory; 

providing, subsequent to the storing the information 
in the context database, the identity to the sched- 
uler; 

searching, by the scheduler, the context database for 
the information related to the client, the server, and 
the interface, to locate the interface; and 

providing the interface to the client firom the context 
database. 

3. The method of claim 2 wherein the context data- 
base is located in a portion of the memory which is 
allocated to the scheduler. 

4. The method of claim 1 ftirther comprising: 
queuing, if the interface was not located in the names- 
pace, the identity of the interface. 

5. The method of claim 1 further comprising: 
releasing, by the scheduler, the single-threaded inter- 
face in response to a completion notification by the 
client. 

***** 
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